The relation relation between technical debt and corrective maintenance in PHP web applications

Context: Technical Debt Management (TDM) refers to activities that are performed to prevent the accumulation of Technical Debt (TD) in software. The state-of-research on TDM lacks empirical evidence on the relationship between the amount of TD in a software module and the interest that it accumulates. Considering the fact that in the last years, a large portion of software applications are deployed in the web, we focus this study on PHP applications. Objective: Although the relation between debt amount and interest is well-defined in traditional economics (i.e., interest is proportional to the amount of debt), this relation has not yet been explored in the context of TD. To this end, the aim of this study is to investigate the relation between the amount of TD and the interest that has to be paid during corrective maintenance. Method: To explore this relation, we performed a case study on 10 open source PHP projects. The obtained data have been analyzed to assess the relation between the amount of TD and two aspects of interest: (a) corrective maintenance (i.e., bug fixing) frequency, which translates to interest probability and (b) corrective maintenance effort which is related to interest amount. Results: Both interest probability and interest amount are positively related with the amount of TD accumulated in a specific module. Moreover, the amount of TD is able to discriminate modules that are in need of heavy corrective maintenance. Conclusions: The results of the study confirm the cornerstone of TD research, which suggests that modules with a higher level of incurred TD, are costlier in maintenance activities. In particular, such modules prove to be more defect-prone and consequently require more (corrective) maintenance effort. (C) 2017 Elsevier B.V. All rights reserved

Architectural decision-making as a financial investment:An industrial case study

Context Making architectural decisions is a crucial task but also very difficult, considering the scope of the decisions and their impact on quality attributes. To make matters worse, architectural decisions need to combine both technical and business factors, which are very dissimilar by nature. Objectives We provide a cost-benefit approach and supporting tooling that treats architectural decisions as financial investments by: (a) combining both technical and business factors; and (b) transforming the involved factors into currency, allowing their uniform aggregation. Apart from illustrating the method, we validate both the proposed approach and the tool, in terms of fitness for purpose, usability, and potential limitations. Method To validate the approach, we have performed a case study in a software development company, in the domain of low-energy embedded systems. We employed triangulation in the data collection phase of the case study, by performing interviews, focus groups, an observational session, and questionnaires. Results The results of the study suggested that the proposed approach: (a) provides a structured process for systematizing decision-making; (b) enables the involvement of multiple stakeholders, distributing the decision-making responsibility to more knowledgeable people; (c) uses monetized representations that are important for assessing decisions in a unified manner; and (d) enables decision reuse and documentation. Conclusions The results of the study suggest that architectural decision-making can benefit from treating this activity as a financial investment. The various benefits that have been identified from mixing financial and technological aspects are well-accepted from industrial stakeholders

The temporality of technical debt introduction on new code and confounding factors

Code Technical Debt (TD) is intentionally or unintentionally created when developers introduce inefficiencies in the codebase. This can be attributed to various reasons such as heavy workload, tight delivery schedule, or developers’ lack of experience. Since a software system grows mostly through the addition of new code, it is interesting to study how TD fluctuates along this process. Specifically, in this paper, we investigate: (a) the temporality of code TD introduction in new code, i.e., whether the introduction of TD is stable across the lifespan of the project, or if its evolution presents spikes; and (b) the relation of TD introduction to the development team’s workload in a given period, as well as to the experience of the development team. To answer these questions, we have performed a case study on 47 open-source projects from two well-known ecosystems (Apache and Eclipse) as well as additional isolated projects from GitHub (not selected from a specific ecosystem) and inspected the number of TD issues introduced in 6-month sliding temporal windows. The results of the study suggested that: (a) overall, the number of TD issues introduced through new code is a stable measure, although it presents spikes; and (b) the number of commits performed, as well as developers’ experience are not strongly correlated to the number of introduced TD issues.</p

The Perception of Technical Debt in the Embedded Systems Domain:An Industrial Case Study

Technical Debt Management (TDM) has drawn the attention of software industries during the last years, including embedded systems. However, we currently lack an overview of how practitioners from this application domain perceive technical debt. To this end, we conducted a multiple case study in the embedded systems industry, to investigate: (a) the expected life-time of components that have TD, (b) the most frequently occurring types of TD in them, and (c) the significance of TD against run-time quality attributes. The case study was performed on seven embedded systems industries (telecommunications, printing, smart manufacturing, sensors, etc.) from five countries (Greece, Netherlands, Sweden, Austria, and Finland). The results of the case study suggest that: (a) maintainability is more seriously considered when the expected lifetime of components is larger than ten years, (b) the most frequent types of debt are test, architectural, and code debt, and (c) in embedded systems the run-time qualities are prioritized compared to design-time qualities that are usually associated with TD. The obtained results can be useful for both researchers and practitioners: the former can focus their research on the most industrially-relevant aspects of TD, whereas the latter can be informed about the most common types of TD and how to focus their TDM processes

How do developers fix issues and pay back technical debt in the Apache ecosystem?

During software evolution technical debt (TD) follows a constant ebb and flow, being incurred and paid back, sometimes in the same day and sometimes ten years later. There have been several studies in the literature investigating how technical debt in source code accumulates during time and the consequences of this accumulation for software maintenance. However, to the best of our knowledge there are no large scale studies that focus on the types of issues that are fixed and the amount of TD that is paid back during software evolution. In this paper we present the results of a case study, in which we analyzed the evolution of fifty-seven Java open-source software projects by the Apache Software Foundation at the temporal granularity level of weekly snapshots. In particular, we focus on the amount of technical debt that is paid back and the types of issues that are fixed. The findings reveal that a small subset of all issue types is responsible for the largest percentage of TD repayment and thus, targeting particular violations the development team can achieve higher benefits

Identifying, categorizing and mitigating threats to validity in software engineering secondary studies

Context: Secondary studies are vulnerable to threats to validity. Although, mitigating these threats is crucial for the credibility of these studies, we currently lack a systematic approach to identify, categorize and mitigate threats to validity for secondary studies. Objective: In this paper, we review the corpus of secondary studies, with the aim to identify: (a) the trend of reporting threats to validity, (b) the most common threats to validity and corresponding mitigation actions, and (c) possible categories in which threats to validity can be classified. Method: To achieve this goal we employ the tertiary study research method that is used for synthesizing knowledge from existing secondary studies. In particular, we collected data from more than 100 studies, published until December 2016 in top quality software engineering venues (both journals and conference). Results: Our results suggest that in recent years, secondary studies are more likely to report their threats to validity. However, the presentation of such threats is rather ad hoc, e.g., the same threat may be presented with a different name, or under a different category. To alleviate this problem, we propose a classification schema for reporting threats to validity and possible mitigation actions. Both the classification of threats and the associated mitigation actions have been validated by an empirical study, i.e., Delphi rounds with experts. Conclusion: Based on the proposed schema, we provide a checklist, which authors of secondary studies can use for identifying and categorizing threats to validity and corresponding mitigation actions, while readers of secondary studies can use the checklist for assessing the validity of the reported results